An IP Multimedia Subsystem (IMS) is a network capable of providing packet voices, packet data, uniform multimedia services and applications. In the IMS, an IP packet-switched domain is used as bearing channels for control signalling and media transmission. The control signalling is a call control signalling based on the Session Initial Protocol (SIP).
The IMS mainly includes the following functional entities: a Home Subscriber Server (HSS) configured to manage user subscription data of the IMS; an Application Server (AS) configured to provide services; and a Serving-Call Session Control Function (S-CSCF) entity configured to implement session control function.
The AS and the S-CSCF are two separate functional entities in the IMS. The AS processes the IMS services triggered by the S-CSCF. Multiple as can cooperate with each other to provide a specific service.
In the IMS, an IMS user accesses the IMS through a Proxy-Call Session Control Function (P-CSCF) entity in a network where the IMS user is currently located. The session and service control functions are implemented by a home serving-CSCF (S-CSCF) entity in a network where the IMS user is registered. As a result, the IMS user can obtain the same service at different access points. Thus, the separation of service management, session control and bearing access is realized, and the access procedure is irrelevant to the position of the IMS user.
When accessing the IMS, the IMS user needs to establish a relationship between the IP address currently used by the IMS user and a public identity of the IMS user, i.e., the IMS user needs to register on the S-CSCF and the AS, so as to establish the relationship which is required during the service implementation. The registration of the IMS user on the AS is implemented by generating a third party REGISTER request by the S-CSCF and sending the third party REGISTER request to the AS. The registration procedure is as shown in FIG. 1 and includes the following steps.
Step 11: A UE initiates a REGISTER request to the S-CSCF. The contents contained in the REGISTER request include, for example:
  “REGISTER sip: scscf.home.net SIP/2.0  Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]; branch=z9hG4bKnashds7  Max-Forwards: 70  From:<sip:zhangsan@home.fr>;tag=6fa  To:<sip:zhangsan@home.fr>  Contact:<sip:  [5555::aaa:bbb:ccc:ddd]>;expires=600000;g.3gpp.cs-  video;  g.3gpp.voice  ......”.
Step 12: After receiving the REGISTER request sent by the UE, the S-CSCF returns a 200 OK response message to the UE indicating that the registration is successful.
Step 13: After receiving the REGISTER request, the S-CSCF checks the downloaded initial filtering criteria (iFC) of the user and evaluates the iFC.
Step 14: The S-CSCF generates a third party REGISTER request based on the iFC and sends the third party REGISTER request to the AS.
The contents contained in the third party REGISTER request includes, for example:
“REGISTER sip: as.home.net SIP/2.0Via: SIP/2.0/UDP scscf.home.fr; branch=z9hG4bKnasctb9Max-Forwards: 70From:<sip:scscf@home.fr>;tag=7ecTo:<sip:zhangsan@home.fr>Contact: <sip: scscf.home.fr>; expires=600000......”.
Step 15: After receiving the third party REGISTER request, the AS returns a 200 OK response message to the S-CSCF indicating that the user has successfully registered on the S-CS CF.
During the implementation of the present disclosure, in the above process, the S-CSCF initiates the registration to the AS for the user. In order to ensure that the AS is able to communicate with the S-CSCF during the registration to the AS instead of routing information destined to the UE directly to the UE, the S-CSCF replaces the UE information (i.e. capability information of the UE) in the Contact header field of the third party REGISTER request with the address of the S-CSCF. Thus, the AS is unable to obtain the UE information and, as a result, services based on the capability information of the UE cannot be successfully implemented on the AS.